rfc20: reserve leading + for instance-local properties - #545
Conversation
|
|
|
|
grondo
changed the title
|
Tweaked slightly to allow properties with leading + to indication "instance local" more generally, instead of just auto-added. |
| themselves, an instance-local property MAY be omitted from a resource | ||
| set generated for a job or a child instance. |
There was a problem hiding this comment.
Would these properties be stripped from allocated R sets (e.g. what gets stored in the job KVS dir) by the scheduler? Or just stripped by the sub-instance resource module when it builds the inventory?
If the scheduler should strip these, the change currently wouldn't require a fluxion change since R is stored via libschedutil.
There was a problem hiding this comment.
I was thinking the scheduler would strip them, but intentionally left that unspecified in the spec.
There was a problem hiding this comment.
To be more clear, by "the scheduler" I did indeed mean the thing generating the resource set for a job, i.e. the R stored in the KVS would have instance-local properties stripped, since they're somewhat meaningless in that context. Whether that is done by the actual scheduler or via something after the fact (libschedutil or the Python equivalent) is probably just an implementation detail and doesn't need to be in the spec (unless you'd prefer that?)
There was a problem hiding this comment.
That seems right to me and you're right, libschedutil vs scheduler is implementation detail. I was asking whether the stripping was occuring in the enclosing instance or the sub-instance. I'm hearing enclosing instnace, which i agree with.
It's probably OK IMHO to be firm and use SHALL here as well as call out that the scheduler writes R and is responsible for this.
There was a problem hiding this comment.
Ok, reworded to:
Because instance-local properties describe the instance and not
the resources themselves, a scheduler SHALL omit them from the R it
generates to allocate resources to a job. Other components that
generate an R subset MAY likewise omit them.
I added the "Other components" language here as a hedge against future work where the scheduler isn't the only thing that can subset an instance R.
|
|
Problem: Flux may add resource properties itself to describe the local instance, such as a property representing queue membership. There is no way to tell such a property apart from one that describes the resource set in general, so a job's generated R may inherit instance properties that have no meaning in a child instance. Define a leading + in a property name to mark an instance-local property and specify that the scheduler should omit these properties when generating an R subset for job. Future proof the specification by stating that other components that generate an R subset MAY likewise omit instance-local properties. Assisted-by: Claude:Opus-4.8
|
|
|
Tick the box to add this pull request to the merge queue (same as
|
2 participants
Problem: There is no way to differentiate properties in a resource set that were applied automatically by Flux apart from a property configured manually, so tooling cannot know which properties describe the instance versus the resources. This leads to allocated R objects inheriting properties that may have no meaning in a subinstance.
Reserve a leading + in a property name to mark a property that Flux added automatically rather than one configured manually. The literal property still applies to its execution target ranks, but because it describes the containing instance it is intended for internal use and MAY be omitted from a resource set allocated to a job.
Assisted-by: Claude:Opus-4.8